COMMENT ⊗   VALID 00001 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂20-OCT-76  0944	RPG  
 ∂20-OCT-76  0403	JRA  	LISP
WHAT ARE YOUR FIRST IMPRESSIONS OF MANUSCRIPT? AND HOW FAR ALONG
ARE YOU? IF YOU WANT MORE, THE NEXT CHAPTER IS ALMOST READY.
					JOHN

	I am pretty much through chapter 2 (reading it fairly
carefully though), and have found some passages somewhat difficult
to understand (difficult in spite of the fact that I understand
what you are trying to get at). In particular, there is the section
on strictness/non-strictness/divergence etc. I have no specific complaints
about it , but I felt uncomfortable reading it the first time. I'm also
not too sure about the real advantage to the t/f vs. T/NIL decision. In some
sense, I view the ambiguity on LISP as one of its features. 
	I can take the next chapter whenever you are ready. I am planning
to really gung-ho it this weekend and be able to give back the commented
version I am reading.
				-rpg-

∂25-OCT-76  1043	RPG  
 ∂25-OCT-76  0358	JRA  	maclisp listing    
the last listing i caught was about 6.5 pounds; that was pre-bibop:1972.
if you can tell me where the file(s) exist, i can list them early in the
morning.
				john

	ok, the source will appear in 1,rpg by Oct 26. it will be called
lisp.nnn where nnn is something like 232.
	I am 3/4 done reading the parts i have and hope to finish tonight.
			-rpg-

∂25-OCT-76  1509	RPG  	MACLISP  
	WELL, JONL AND I ARE NOW TRYING TO FLUSH THE NON-BIBOP CODE,
SO IT IS NOT IN A GOOD STATE TO LOOK AT.
			-RPG-

∂28-Oct-76  2107	RPG  	BOOK
	I have finished the first part of the book and have the following
general comments:
	The parts on data structuring seemed to me to be forced. It may
be that I have some residual bigotry on my part, but I felt that it
didn't roll to easily.
	On the other hand, I felt that the sections on EVALuation and
spaghetti were among the best I have read in that area (i.e. excellent).
The implementations were quite understandable and the points were well
made. 
	More specifically, the comparison or analogy between mathematical
definitions and data structuring appeared to be very unnatural, although
I felt that the points made were good. 
	On spaghetti, my feeling is that it is undoubtedly something for
people who use LISP should know about, but it may not be something that
is ever useful in practice. I have personally never known anyone who has
used it in anything like a production program (except me), and almost none
who have even used it except to see how it works. It seems that there is
always a better way to achieve ones ends than by a general purpose &
inefficient features. Spaghetti invariably saves too much information, tends
to favor lexical variables (especially when you usually want fluid), and forces
laziness on the part of the hacker. For instance, I wrote a hairy pattern
matcher once which required real bactracking in a car/cdr recursion (not a
simple tree search). The matcher often had to bactrack into a control frame
that had been exited. Well, in LISP370 I used spaghetti, and in MACLISP I
explicitly used continuations, which clarified control and was fairly efficient
through the compiler. (the idea was to make the cdr recursion a sub-computation
of the car recursion as opposed to a sister computation). I plan to recode
the LISP370 version soon. 
	Another point concerns the use of continuations in the book. It
seems that they only appear briefly, as a passing concept between recursion/
subroutine returns and PC control. Well, either continuations should be
presented as a programming skill on its own, or it should be flushed as
a puzzling interlude, or some comment might be derived about its intermediary
position wrt stack control style and Program Counter style.
	I am always puzzled about the use of a "LISP Metalanguage" which is 
separate from the S-expression notation. I am not questioning the usefullness
of the metalanguage as a theoretical tool of great importance, but the 
of it as a pedagogical tool. When I TAed 206 for McCarthy, I saw the
bewilderment it caused when the two notations were introduced in parallel.
A point this "algolishness" seems to obscure is the natural ambiguity inherent
in LISP, namely between the program and the data. Now, I am definitely
not trying to say that it is the ability of LISP to write programs and execute
them which makes i such a nifty language, but that the ability to cons up
certain restricted expressions which can be later applied on a small scale
(that is the handles on the evaluator) that make it a useful language.
	A point that you don't seem to make is that LISP is an environment that
the user can sit inside of while his programs suffer trauma, and not a
compiler-based language in which you create your poooooor program, and boot
it into the confusing world of the compiler, tto suffer alone in the cruel
world.
	I guess LISP is naturally a hacker's programming language, in that
every nifty hook is available, and you can either hang yourself or not
according to your own abilities.
	An important aspect of any comprehensive discussion of LISP is why
it is that such an obscure looking language should be preferred by AI
hackers.
	Well, I look forward to the next sections of the book, and will
put the commented first part in your mailbox, if you have one, or mine.
				-rpg-

∂10-Nov-76  1351	RPG  	PROGV Feature 
To:   MACLSP.DIS[AID,RPG]:; 
Here is a little known feature of Maclisp that may be of some
use:

    (PROGV <VAR-LIST> <VALUE-LIST> <FORM1> <FORM2> ... <FORMN>)
    EVALUATES <FORM1> ... <FORMN> AS A PROGN IN AN ENVIRONMENT
    CREATED BY BINDING THE SYMBOLS IN <VAR-LIST> TO THE
    RESPECTIVE VALUES IN <VALUE-LIST>.  THAT IS, THE FIRST
    TWO ARGUMENTS TO PROGV ARE EVALUATED; THE FIRST MUST
    PRODUCE A LIST OF SPECIAL VARIABLES, AND THE SECOND
    A LIST OF VALUES.  THE VARIABLES ARE THEN BOUND TO THE
    VALUES.  IF TOO FEW VALUES ARE SUPPLIED, THE REST OF
    THE VARIABLES ARE BOUND TO NIL.  IF TOO MANY VALUES
    ARE SUPPLIED, THE EXCESS VALUES ARE IGNORED.
    THE BODY OF THE PROGV IS THEN EVALUATED AS A PROGN,
    THE VARIABLES UNBOUND TO THEIR OLD VALUES, AND THE
    VALUE OF THE LAST FORM IS RETURNED.
    EXAMPLE:
	(SETQ A 'FOO)
	(SETQ B 'BAR)
	(PROGV (LIST A B 'B) (LIST B) (LIST A B FOO BAR))
		==> (FOO NIL BAR NIL)


∂10-Nov-76  1622	RPG  	Book
	The static structure section is in my box.
I did not find it as well wriiten as the evaluator sections.
In particular the treatment of shallow binding was
misleading/incomplete.
			-rpg-

∂11-Dec-78  1724	RPG  	NEWIO programming tips  
To:   "@MACLSP.DIS[AID,RPG]" at SU-AI 
	When compiling a file, if you want to do a require, just say:

	(REQUIRE ...)

rather than the older:

	(DECLARE (REQUIRE ...)) 

or whatever. NCOMPLR knows about REQUIRE.
The useful feature EVAL-WHEN can be used to do things in the compiler
environment much like a DECLARE:

	(EVAL-WHEN (COMPILE) (DEFUN ZTESCH MACRO ...))

You can also have LOAD and EVAL appear in the options part as well as
the COMPILE. If EVAL and LOAD appear then the form will be EVALed at LOAD time.

 	(EVAL-WHEN (COMPILE) (DEFUN FOO MACRO (X) 'FOO))

is totally equivalent to 

   	(DECLARE (DEFUN FOO MACRO (X) 'FOO))

and

   	(EVAL-WHEN  (EVAL COMPILE) P1 P2 . . . PN)

is equivalend to 

   	(DECLARE (EVAL (READ)))
   	(PROGN P1 P2 . . . PN)

finally, one wants a way to cause something to happen during loading
of the compiled code - that is what the LOAD options is.

   	(EVAL-WHEN (LOAD EVAL) (PRINT 'LOADING-MY-SYSTEM))

∂21-Dec-78  1219	RPG  	Bug fix in NEWIO   
To:   "@USERS.DIS[AID,RPG]" at SU-AI  
	A bug wherein part of the LISP reader believed itself to be
in linemode and part in character has been patched using partial
knowledge. This means that the patch may or may not work, and even
might cause further bugs. Things which could conceivably be effected
are input from non-data-disk/datamedia terminals, programs using
tyipeek, and some kinds of disk IO. Symptoms of further lossage could include
waiting for input when there shouldn't be any, reading too much stuff, etc.
			-rpg-

∂22-Dec-78  1630	RPG  	DEFUN change. 
To:   "@USERS.DIS[AID,RPG]" at SU-AI  
The first atom in a DEFUN is ALWAYS interpreted as the name of the function.
So in (DEFUN FEXPR MACRO ...) FEXPR is the name of the MACRO being defined.
				-rpg-

∂09-Jan-79  1542	RPG  	MacLisp matcher    
To:   "@USERS.DIS[AID,RPG]" at SU-AI  
Here's some changes to %MATCH you matcher fans:
;;;;;;;;;; the matching function ;;;;;;;;;; 
;;;
;;; (arg 1) - p -     pattern
;;; (arg 2) - d -     data
;;; (arg 3) - alist - optional list of variables (* or ?) whose values
;;; 		      are to be retained during the match, much like the
;;;		      = variables below.
;;; elements of a pattern:
;;;	? 	- matches anything
;;;	* 	- matches one or more expressions
;;;	?<atom> - like "?", but sets ?<atom> to thing matched
;;;	*<atom>	- like "*", but sets *<atom> to list of things matched
;;;	=<atom>	- matched against value of <atom>
;;;	(restrict <one of above ?-variables> <pred1> <pred2> .....)
;;;		- the predi must eval to non-nil
;;;	$r, ⊗r  - same as RESTRICT
;;;	(restrict <one of above *-variables> <pred1> <pred2> .....)
;;;		- the predi must eval to non-nil when given the list
;;;		  that is being considered for that variable as its argument
;;;	(irestrict <one of above *-variables> <pred1> <pred2> .....)
;;;		- the predi must eval to non-nil when given each element of the list
;;;		  that is being considered for that variable as its argument 
;;;		  (done incrementally). So %MATCH will apply these predicates as
;;;		  it scans the input.
;;;	$ir,⊗ir - same as irestrict
;;;
;;; (%match p d <variables to retain>) attempts to match p against d
;;; (%continue-match p d <variables to retain>) attempts to get the next
;;;		  possible match between p and d (by different *-variable
;;;		  bindings.
;;*PAGE

∂17-Jan-79  1546	RPG  	UTIL.>   
To:   "@USERS.DIS[AID,RPG]" at SU-AI  
	To speed up compilation (and interpretation), you might try changing your
(require util 1 dsk (aid rpg)) to
(declare (fasload '((dsk (aid rpg)) util fas)))
			-rpg-